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* ' REVIEW OF THE IHS ARCHITECTURAL FUNCTION IN THE AGENCY 


OBJECTIVE OF THE OFFICE OF THE IHSA 

The Office of the IHSA was established in January 1981 in 
accordance with the directions of the EXCOM, based on its review of 
the findings and recommendations of the Information Handling Task 
Force. The office was established to plan, coordinate, guide, and 
approve the overall design of the Agency's information handling 
systems (IHS) . The objective is to achieve an integrated, non- 
redundant total Agency IHS architecture that is responsive to the 
totality of user needs, while maximizing the payoff for the 
investment. The IHSA also is to serve as the prinicipal focal point 
for community contact and top-level information concerning the status 
of the Agency's IHSs. The office function is one of top-level 
management and planning, and does not involve development of system 
requirements or system implementation. 

FOCUS OF THIS PRESENTATION 

The IHSA has been assigned the responsibility of making an annual 
report to t)ie EXCOM on the status of IHSs in the Agency. In this 
first report, the focus is on the key problems and proposed approach 
of the office of the IHSA in dealing with those problems. 

In the memorandum reporting the conclusion of the EXCOM, it was 
stated that "The Committee agreed to adopt the proposed mission and 
function statements for the time being and review them for possible 
revision after the 'architect' has been in operation long enough to 
evaluate them." The office has now been organized, the staff 
selected, and has begun operation on the basis of the proposed mission 
and function statements. Principally, these are the mission and 
function statement of the Architect of Information Services that was 
prepared by the DDA in response to EXCOM guidance. It is now 
appropriate to review that mission and function guidance and change 
and ratify it as appropriate, in accordance with EXCOW findings. 

Clear guidance and a statement of missions and functions, from the 
EXCOM to the IHSA, is needed to direct the office and establish its 
acknowledged role in the Agency community. 

Since discussing the entire package of findings and 
recommendations would be an excessively long and generally 
unproductive undertaking, this report focuses on the key problems and 
the recommended approach and authorities of the IHSA to deal with 
them. The concern is with key problems found by the IHSA, but for 
which no recommendations were made, and with other issues found by the 
IHSA to be fundamental to the execution of the general IHSA 
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responsibility. Issues and approaches which are felt to be non- 
controversial are assumed to be accepted and have been omitted from 
discussion for the sake of brevity. 

THE KEY PROBLEMS AND THEIR RESOLUTION 


In the following paragraphs, the key problems in accordance with 
the above stated criteria, and as perceived by the IHSA are presented. 

1. Approval of Systems 

I believe the current top-level management involvement for IHSs to 
be primarily budgeting. The Directorates operate on the philosophy 
that: once the money is available, spending it on the designated 
subject is at the discretion of that Directorate. In other words, it 
is a local-option environment. 

I do not believe that the function of the IHSA has any significant 
value unless top-level management is instituted with respect to IHSs 
and this office plays a key role in that management. That is the only 
way IHSs can achieve interoperability as part of a larger 
architecture, precious resources can be used to develop and operate 
systems in an efficient and effective manner, and the planning and 
environment needed to support sysems development can be created. 


The extant guidance on the approvals is scant and is contained in 
a DDCI memorandum of 26 July 1978 (DCI 78-8710/16) . It specifies that 
all projects with an annual investment cost greater than $250,000 will 
be reviewed annually by the EAG (predecessor to the EXCOM) . It does 
not specify any initial required documentation, such as functional 
requirements, development plan, or costs. There is also overlapping 
guida nce with respect to ODP approval of ADP systems and ADPE in HR 


I l of 13 August 1975, which defines ODP's charter, 
specifies approval auth orities wh ich are redundant to 
the 
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Agency discretion with respect to the formulation of its top 
management process has recently been somewhat limited by two recent 
actions. Section 3506 of the Paperwork Reduction Act of 1980 
specifies that each agency shall appoint a senior official, reporting 
to the agency head, to carry out agency responsibilities under the 
act. These include review, planning, budgeting, and training with 
respect to IHSs. Even if the Agency receives a general waiver from 
the terms of this act because its systems relate to such activities as 
the collection of foreign intelligence, the intent of Congress that 
there be a single, designated, agency management and control point for 
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IHSs is clear. 
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The second action derives from the Agency's request, along with 
those of several other agencies, for a general delegation of authority 
for waivers from the NBS Federal Information Processing Standards 
(FIPS), managed for the Governnment by the Department of Commerce. In 
its letter of 6 April 1981, the Commerce has responded that it is now 
coordinating action "to amend the FIPS to delegate to heads of 
agencies the authority to approve waivers." It is the view of NBS 
that the letter represents a statement of clear intention to delegate 
the waiver authority by DOC, subject to approval by OMB and possibly 
Congress. The delegation would be made in a formal instruction that 
clearly specifies the acceptable conditions for such waivers. As in 
the Paperwork Reduction Act, a senior individual reporting directly to 
top-Agencv management would have to be delegated the waiver management 
responsibility. This individual should not also be responsible for 
systems implementation, but would review the waiver requests of 
parties responsible for such systems implementation. 

We thus have three factors pointing towards the necessity of 
assigning the IHSA approval authority of IHSs: the basic need for 
top-level, centralized management of IHSs; the agency responsibilities 
under the Paperwork Reductions Act; and the DOC delegation of waiver 
authority with respect to the FIPS. Even if the EXCOM had not 
recommended such authority, it would seem to be mandatory at this 
point if the Agency's top-management responsibilities are to be met. 

2. Accreditation of System Requirements 


The source of the problem is probably the old aphorism, "The user 
is responsible for requirements." While this functional assignment 
sounds logical, it is a simplistic concept that can lead to real 
problems if interpreted as the delegation of an exclusive prerogative 
to the user. Some of the principal sources of such problems are: 

o Lack of a reconciliation of the user's requirements 
with the implementation environment; 'y 

o Inadequate attention to adjunct user requirements; 
and 

o Lack of a consolidation and validation mechanism 
for requirements derived from a community of users. 
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The lack of reconciliation involves an interactive process 
user and developer. The system requirements should evolve 
functional requirements as the consequence of an interplay 
techniques and mechanisms of their implementation and the 
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restructuring of user organizations or operations in conjunction with 
, the?new system. One of the worst mistakes that can be made is simply 
to automate current manual procedures; the result is usually a system 
several times the size and cost as would satisfy the need. The 
implications of such a direct transformation approach are not always 
well understood by user organizations. 

With reference to adjunct requirements, there is an increasing 
functional complexity of Agency systems due to the increasing 
irivdlvement of adjunct users. Instead of a system like PERSIGN, which 
is a personnel management system with a homogenous set of users, we 
are now developing systems like LIMS, a logistics system with many 
adjunct user organizations. The problem of the definition of the 
requirements for such a system can be difficult, particularly when an 
IOC date and funding constraints force compromises. 

Lastly, there is the problem of requirements for general services 
systems. The requirements for these systems drive their cost, 
availability, and acceptance just as they do for any other. The 
problem is the establishment of an acceptable, but not excessive, set 
of requirements. The Agency history has been that the developer sets 
the requirements for such systems, based on user surveys and/or 
projections of historical use data. A distinct hazard with this 
process ohce it has begun is the natural migration of management 
concern to the technical issues of implementation, to the detriment of 
user interest. 

All of these examples reflect a strong need for accreditation of a 
new systems functional requirements. For complex systems, this can 
only be done at an Agency-wide level, since the problem is an 
ecumencial one. It also requires concentrated top-level attention, 
since the problems are complex. They cannot be successfully dealt 
with in an EXCOM-type project review unless the key issues and 
tradeoffs have already been identified and analyzed. 

3. Lack of Systems Development Guidance and Training 

The Agency is in an almost unique position among \ma jo r Government 
agencies in providing no Agency-wide guidance for the development of 
IHSs. Some formal guidance has been developed in some groups, and 
there is a lot of high-powered expertise, but little of it has been 
formalized, even at the group level. 

This lack of guidance is a major problem because there is a 
tremendous variation in the way developments are done among groups in 
the Agency. Compounding the problem is the fact that because of the 
constrained budget situation, experience in the development of large 
or moderate-sized systems is quite limited. While Agency experience 
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the study is appended (Appendix B) . Precise results were not 
available because components, for the most part, had not begun to 
think specifically about and plan for the problem. Basically, 
however, it shows that a very substantial jump in the Agency-wide IHS 
training requirements is imminent. This is compounded by the fact 
that we are not even keeping up with our current training requirement. 


To bound the problem, OT&E estimated the resources required if all 
the training, including component-unique training which is normally 
done by the components, were done centrally. They found that their 
resources in terms of people, space, and equipment dedicated to the 
purpose, would approximately havb to triple. This estimate also was 
base<d on the assumption of totally scheduled training, that is no ad 
hoc training. Actually there is ad hoc training, and the more 
distributed it is, the higher the proportion of the total it 
represents. Ad hoc training significantly decreases the efficiency of 
training^ These would also be component-unique training done by the 
components, again decreasing efficiency. 


Very clearly, if this IHS training requirement is not centrally 
managed, there will be a substantial growth in component training. 
Each of the Directorates would shortly have IHS training centers and 
dedicated resources several times that currently existing in OT&E. I 
would estimate that such a distributed training approach would be no 
better than about half as efficient as a centralized one. 


A greater concern, however, is the development of a common IHS 
culture. Distributed IHS training would destroy any possibility of 
developing such a common IHS culture within the Agency. Developing a 
training program that will meet all the needs of the Agency will 
require top-level guidance and support. 

The other part of the environment problem is the development of 
standards. We need standards in three areas relative to IHS 
development: 

• \ ..... 

o Management procedures and development processes standards 

o Interface control standards 

o Data item specifications (e.g., per CDRL) 

Examples of documents in each category exist, some of them excellent. 
But these are not standards or guidances even at the Directorate 
level. A moderate or large-sized systems development can readily 
require the adherence to or production of 20 different documents. For 
the project personnel to figure all that out de novo is an 
unreasonable requirement, and it certainly is not going to produce a 
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homogenous environment. It is, however, our current situation. The 
ability of systems to interoperate in a unified architecture is 
probably as much a function of how they are built as what interface 
requirements are levied upon them. 

In order to have a single set of standards and have them for the 
entire Agency we need centralized development and promulgation of such 
standards* 

4. Robustness and "User Friendly" Systems 

Over the past five to ten years, I believe the impact of the 
tightly constrained Agency budgets has been to force the IHSs into an 
increasingly cost-effective posture. Unfortunately, this increase 
costi-ef f ectiveness has been achieved at the expense of robustness. As 
a cdnsequence , we now have highly fragile data processing and 
communications systems architectures. User availability of the 
central systems is significantly below expectations, point failures 
tend to cascade through the systems, and the ability to respond to 
contingencies is not adequate for an Agency that is to support 
contingency and wartime operations. 

Robustness, like security, costs money and contributes little, if 
anything, to performance. Working our way out of the fragility corner 
requires reordered priorities and an advocate the user’s concern 
tends to be with solving his immediate problems and the supplier of 
the service with meeting the user's needs. Robustness is an_ 
architectural concern and one that needs concentrated attention in the 
near term future. 

As our user base expands rapidly, we need to develop "user . 
friendly systems." We have made a very substantial investment in 
developing our central systems and have now, as a consequence, some 
unique and remarkable capabilities. We also have a system that 
requires high degree of expertise to use in many areas. Expertise, 
unfortunately, can also be correlated directly with the amount of 
training required. 

User friendly systems involve both the simpler interfaces, as seen 
by users on their visual display terminals (VDT ) , and simpler, 
facilities. This greater use of menu— driven functionalities is needed 
so that users will not have to become experts in the instruction sets, 
operational structure and syllogism of particular functionalities, 
such as a data base management system. We also need simple 
functionalities for the facile implementation of small-scale 
applications. Users become frustrated when they have to learn how to 
use complex functionalities in order to perform a simple task. 
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Development of "user friendly" systems requires priority and 
investment. The user payoff is diffuse and hard to measure. As a 
consequence, I believe achieving it requires an advocate to guide and 
support it. 

5. Scientific Programming 

j Scientific prpgramming to support intelligence analysis is a 
particular problem area at the present time. The Agency used to have 
a group dedicated to scientific programming, but there were a series 
of reorganization moves involving it, and gradually, its members 
either left the Agency or joined user groups. We no longer have a 
scientific programming group and I believe this to be a major concern. 

1 We have some highly skilled individuals in analytic user 
organizations, but not many. We are plagued by the problem that such 
individuals can command high salaries in the commercial market place 
where their promotability is not hampered by a need to move into 
management, as it tends to be here. Here their careers cap out fairly 
quickly if they are in an intelligence analysis career path, and the 
only option they have to continue to advance their career is to leave. 

Because we have lost the scientific programming group and cannot 
retain highly skilled scientific programmers in user organizations, 
the Agency now primarily depends on contractors for scientific 
programming support. Using contractors is certainly not a problem, 
but depending on them is. I understand the impact on our program was 
severe when one contractor recently had to be terminated because of 
security violations. When we lack a solid in-house scientific 
programming resource base, we are in a very tenuous position. In 
addition, I believe the demand for scientific programming is likely to 
be rapidly increasing. It is typically what happens next after 
analysts learn how to operate on a terminal and get word processing 
and analyst file functions under their belts. \ \ 

; \ ... 

Rebuilding a scientific programming capabi 1 ity ' is going to take 
top-management attention. I believe that we need to develop a 
"critical mass" of such people in a coherent organization with a clear 
career path. They need to see SIS-level scientific programmers in 
leadership positions and an appropriate GS grade-level profile. 
Obtaining these conditions implies organizational changes in both 
implementing and user organizations to achieve an environment 
attractive to such highly skilled people. Only with the Agency career 
attractiveness could we afford to hire and make the substantial 
continuing education investments that such personnel require. 

6. Efficient Utilization of the IHS Resources 
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My perception is that there has been a tremendous shift in 
attitude within the Agency regarding IHSs just within the past several 
years. A few years ago, most professionals with analytic or 
operational responsibilities seemed to view IHSs as an arcane 
technology that was the province of highly trained specialists. Today 
I believe the current perception to be that an ability to utilize IHSs 
is important to all professionals if they are to develop and apply 
their skills at a level of effectiveness reflecting the contemporary 
environment. 

This very rapid growth of interest has produced an explosion of 

demind. Very clearly, our IHS user community is going to expand by an 

order of magnitude in just a few years. Managing that explosion of 

demand to provide efficient use of the IHS resources is a major 
concern. Given our budget constraints, the penalty for not ^ 

effectively managing that demand is going to be falling badly behind 
in terms of processing, storage, and applications development. 

The provision of IHS resources in the Agency has-been based on a 
top - management review and budgeting process. The guiding philosophy 
for this process is understood to have been the provision of whatever 
is needed to get the job done. A primary objective has been 
identified as "encouraging innovation" and the use of "computer 
resources, as opposed to human resources, by making them free to the 
user. 

I believe we have passed through the era v/here we need to 
encourage the use of IHSs and are now approaching one in which the 
emphasis should fall on managing it for efficient utilization. We 
have a limited amount of time to prepare for a certainly predictable 
future. If we do not use this time effectively to develop needed 
procedures and implement functionalities, then we are going to find 
ourselves "behind the power curve." It is a very difficult position 
from which to extract an organization in an environment of rapidly 
advancing demand and technology. \ ' \ 

> \ .. 

There are two areas of IHS use that, I believe, need attention: 
on-line data storage and processing. (There are also problems in this 
context relevant to applications development of which the need for 
"user friendly systems" was discussed.) 

While the current information/data generation rate is nigh, it is 
going to increase substantially. The exploitation processes 
associated with overhead collection systems are generating data at an 
astonishing rate and are due to increase by a factor of maybe four in 
just a few years. There is also the steadily increasing inf lux of 
cable traffic from a variety of sources for analysis by intelligence 
analysts. In addition we are acquiring powerful word processing 
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equipment to be broadly distributed throughout the Agency and operate 
off the central systems. This type of equipment approximately doubles 
the productivity of a typical staff. 

All of these sources produce data that is being retained on disk 
for real time retrieval. The Ruffing Center disk farm, for example, 
now almost totally fills its allocated first floor space and is still 
growing. A large part of this data could be eliminated by tape 
storage* archival, and purging. There usually is no justification for 
keeping special applications programs, data or allocated space on-line 
when there has been no activity regarding it for months. Much of the 
data, particularly that generated in the WP context, is simply the 
detritus of the daily work of the Agency's professionals and should be 
disposed of. 

The Other efficiency issue is the use of our processing resources. 
There are several key dimensions to this concern. We need to: 

0 Establish an effective priority system that enduces 
users with lower priority processing to accept longer job 
turnarounds, offloading peak hours. 

o Focus on using the most efficient program that will 
meet the needs of the instant problem, and the latest most 
efficient analytic technology in developing analytic tools. 

o Provide motivation for the management of operational 
systems to invest more of their enhancement resources in 
improving the applications system efficiency. 

Our processing resources are sized very much like electrical power 
generation systems — offloading the peak hours reduces that 
requirement. We need to motivate users in similar manner to use off- 
prime time hours. For example, can an interoffice message * 

appropriately be processed in batch at night for delivery the next 
day, or must it go to the addressees immediately; can a sequence of 
fourier analyses of missile data be packaged for a night time batch 
run, or must they be done one at a time in prime time as they are 
analyzed? 

In developing on-line systems, the primary emphasis is on meeting 
the functional specifications instead of efficiency. After they 
become operational, however, the enhancement process begins. In 
environments where there are dedicated resources supporting the system 
and they are saturated, there is no shortage of motivation for 
efficiency. Users annoyed by slow system response provide plenty of 
it. In shared processing resource environments, however, motivation 
is needed. Otherwise the user is naturally inclined to want all the 


10 


Approved For Release 2 


90R00040003001 0-2 


Approved For Release 2003/06/20 : CIA-RDP84B00890R000400030010-2 

CONFIDENTIAL 

enhancement resources to be invested in new functionalities. 

Hardware technology continues to advance rapidly in the data 
processing environment. More powerful processors and higher density 
on-line storage devices are continuously being offered, and assuredly 
we will continue to take advantage of them. We are talking, however, 
about going from 300 to 3000 on-line users in three years. That is an 
explosion of demand that I do not believe technological replacement 
alone can keep up with. It is certainly the history of the data 
processing industry that users develop new applications at a pace that 
outstrips technology. I see no basis for assuming that will change; 
rather, that our planned explosion in demand will only exaccerbate it. 

Overall, there do not appear to be adequate forcing functions or 
motivators to control the distribution of data, limit its retention, 
use processing resources in the most efficient manner, and develop 
efficient applications packages. We rely on a few administrative 
procedures and ad hoc reviews by ODP. We also have our data disposal 
problem compounded by the archaic regulations of the National Archives 
Record Service (NARS). While we need to refine our administrative 
controls arid get relief from the archaic NARS regulations which deal 
in "records" and not "data," neither is likely to be adequate to deal 
with the problem. We need a coordinated and centralized approach to 
efficient use of IHS resources. Better control functionalities 
resident in the central system, and greater motivation for the users 
to use the resources efficiently are needed. 

It takes time and priority sponsorship to develop the needed 
system utilization control tools. Relief from the archaic NARS 
regulations I believe requires that we take a constructive approach 
and define regulations that we believe will work and make sense in our 
environment. If our data control environment has notchanged 
substantially two years from now, I believe we will find our ability 
to advance our IHS capabilities absorbed by wasteful and non- - 
productive service and administrator requirements. . \ 

\ \ 

RECOMMENDED ACTIONS CONCERNING THE IHSA '' - 

My specific recommendations in approximate order are as follows. 

1 . IHSA Accre dit System Requirements and Approve Systems at Major 

Milestone Reviews 


To define a managerially practical environment, it is recommended 
that there be three categories of systems: Class I (large). Class II 
(medium), and Class III (small). The two thresholds defining the 
boundaries are acquisition cost values. It is recommended that the 
top-management responsibility for the smaller two be delegated to the 
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Directorates, and that the Directorates delegate that for the smallest 
to the constituent Offices. An exception to all such delegations is 
systems with multiple user components, viewed from the next higher 
level. 

The Recommended top-management review process consists of three 
milestones: the planning milestone, which is a budgetary milestone 

and which should interface with periodic budgetary processes; the 
system specification milestone, which is a management milestone; and 
the preliminary design review milestone, which is a management 
milestone. The scheduling of the last two are determined by the 
characteristics of the project, and are not synchronized with any 
peribdic process. This basic management review process would apply to 
all three categories of systems, and there should be documentation 
requirements for each milestone. Review of the conformance of 
developments with documentation requirements for delegated 
responsibilities v/ould be done by the Inspector General's office as 
part of their regular periodic management audit of offices. 

A format for such a top-management process for managing the 
development of systems is attached as Appendix A. This format was 
prepared because it became clear that it was important to clarify the 
mechanism of the intended approval authority for the EXCOM to be able 
to make a knowledgeable judgment. 


It is recommended that the IHSA be authorized to develop a DCI 
Directive concerning accreditation of requirements and approval of 
systems based on this format as it may be modified by the EXCOM. 

It is recommended that the system approval responsibilities 
currently assigned to ODP be assigned to the IHSA, per the approved 
format, in the update of I ~| and a new HR defining the 

responsibilities of the IHSA. In this context it is the intent^of the 
IHSA to delegate responsibility to ODP for review of all ADPE embedded 
in new systems for compliance with FIPS, and conformity with our 
central environment where appropriate. ADPE not embedded in new 
systems would remain the direct responsibility of ODP. The interest 
of this structure is to assure that developers of new systems have 
only one review point, and that the review that is provided is as 
thorough as is the current process. 


2. IHSA Prepare and Promulgate Agency-wide Procedures and Standards 


Pursuant to the IHSA responsibilities under | | ODP has 

passed responsibility for the Agency Standards Committee to this 
office. It is recommended that the IHSA's chairmanship of this 
committee and responsibility for promulgating the Agency's procedures 
and standards, supported by this committee, be affirmed. 
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3. THSA Plan and Guide IHS Training 


It is recommended that the IHSA provide the top-management . . 

guidance and support needed to establish a central ized . IHSs training 
program. This program would focus on non— component unique IdS 
training and be implemented within OT&E. 


The process should proceed along three paths simultaneously: 
there should be a follow-on to the training requirements study 

with all of the Directorates tasked to work with OT&E 
comprehensive and specific statement of IHS training 
for the fiscal year 1982 through 1985; OT&E should 
implications to the organization staffing and regular 
lcm uubwhw of" the Information Sc ience Center of the cost of 
centralized training requirements identified m Appendix B; ana 
contractor provided training should be procured by OT&E to respond 
the immediate training needs of the Agency. A hold should be put on 
the expansion of component IHS training and by botn indigenous and 
contractor personnel until the definitive study is complete and 
decisions made. The IHSA will guide the two study efforts and the 
contractor-based quick-response training. 


(Appendix B) 
developing a 
requirements 
evaluate the 
requirements 
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4. IHSA Gu ide Resource Allocations with Respect — to — Long — Ranqe 
Architectural Investment Planning 


It is recommended that the IHSA have authority to task various 
Aqency offices responsible for the provision of IHS services to . 
perform studies of system architecture alternatives relevant to their 
systems. The studies would be designed to support ooth the strategic 
planning responsibilities of the IHSA and more immediate concerns 
relevant to robustness and provisions of "user friendly" systems. 


The objective of these evaluations 
an adjacent of new investments, rather 


will be to achieve through as 
than to restructure the 
exis ting^sys tem--*in*o the r words , to take the more economical approach 
of "working our way out." On the basis of the studies, the IHSA . 
should review the office resource allocations, and adjust priorities, 
where appropriate, to begin achieving robustness and "user friendly 
system objectives. 

5. IHSA Guide and Direct the Establishment of a scientif ic 
Programming Capability 


It is recommended that a scientific programming capability be 
established within ODP to support scientific programming requirements 
Aqency-wide. The group would be relatively senior, compared to the 
data processing applications development staff. Initially the group 


Approved For Release 


90R000400030010-2 


Approved For Rel<^|^|q|JI|j^^y^JI^B00890R000400030010-2 


would have twenty mathematical programmer slots, the majority drawn 
from ODP's 1983 programmer increase of 35. 

The iHSA should be tasked to direct a joint study with NFAC and 
ODP to determine the organization, placement and method of operation 
of this group. The objective of the study is to determine the best 
way to provide thrust of an environment needed to make an Agency 
career attractive to such personnel, while meeting the operational 
requirements of NFAC and the management requirements of ODP. The 
study report will be made to the EXCOM. 

6. IlHSA Chair a Committee to Examine Methods for Improving 
;Ef f ic iency of Utilizations of IHSA Resources 

It is recommended that the IHSA be tasked todevelop a set of 
recommended techniques for controlling the efficiency of utilization 
of IHS services. It is recommended that a committee with Agency-wide 
representation be appointed to advise the IHSA in the development of 
this package. To be specifically included are user monitoring 
systems, developing an Agency proposal for a revised NARS regulation 
governing records disposal, and chargeback. A report will be made to 
the EXCOM pf the evaluations made and recommended actions. 

7 Publica tion of a Revised Headquarters Notice Signed by 
the~TICT 


It is recommended that a revised Headquarters Notice be prepared 
and promulgated, pursuant to the findings and direction of this EXCOM. 

In order to avoid lengthy staffing delays, it is recommended that that 
notice be part of the findings documentation. ILLEGIB 
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APPENDIX A 


Policy end Procedures for Management for Information Systems 

A. PURPOSE 

' ! 

This document is to set forth Agency policy regarding 
management responsibilities for the acquisition of new or 
enhanced Information System capabilities. 

- r 1 ' 

B. APPLICABILITY AND SCOPE 

The provisions of this document apply to automated or other 
clearly identifiable processes used for creation, movement, 
use> storage, retrieval, or dissemination of intelligence and 
management information. Included are ADP hardware and 
software systems, communications sytems, terminals, word- 
processing, printers and copiers, image processing and 
display, and collection systems. 

C. POLICY 

1. General 

Information System acquisitions shall be reviewed and 
approved at decision milestones by appropriate management 
levels. Systems of extraordinary cost, risk, or interest 
shall be reviewed by the EXCO.M; the Information Handling 

Systems Architect (IHSA) and the Program Management 

Component shall support the EXCOM review process. 
Information Systems falling below the EXCO.M ’review 
threshold, but nevertheless important in the 'context of 
Agency Information Systems Architecture and Planning, may 
be reviewed by the IHSA at decision milestones. 

2. Specific 

For purposes of management and coordination there are 
three classes of information systems, determined by 
investment cost thresholds. Class I and II systems shall 
comply with the procedures, standards, and documentation 
requirements for major programs. Class III programs 
shall comply with the procedures, standards and 
documentation requirements for minor programs. 
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a) Class I Informations Systems shall be reviewed and 
approved at decision milestones by the EXCOM. Any 
Information System, or any significant revision of an 
existing Information System, meeting any one of the 
following criteria shall be designated a Class I 
Information System: 

i) Has anticipated acquisition costs in excess of 
$8 million during the span from program 
initiation to the time the system becomes 
operational; or 

ii) Has estimated costs in excess of $2 million in 
any year; or 

iii) Is designated as being of special interest. 

iv) Information Systems which do not meet the 
criteria for Class I Information System 
designation, but which are considered to have 
Agency- wide or community importance shall be 
reviewed and approved by the IHSA. In 
particular, a number of information systems of 
similar character, but less than Class. I 
threshold, may be aggregated and considered as 
a Class I system. Review procedures used for 
such Class I systems will be tailored as 
appropriate by the IHSA. 

b) Class II Information Systems shall be reviewed and 
approved at decision milestones by the Deputy 
Director responsible for the system. Any Information 
System, or any significant revision of an existing 
Information System, meeting any of the following 
criteria shall be designated a Class II Vrnformat ion 
System: 

i) Has anticipated acquisition costs in excess of 
$1 million during the year from program 
initiation to the time the system becomes 
operational; or 

ii) Has estimated acquisition costs in excess of 
$250,000 in any year; or 

iii) Is designated as being of special interest. 

c) Class III Information Systems shall be reviewed and 
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approved as the responsible Deputy Director may 
direct. In general, it is anticipated that he will 
delegate that authority to the next lower level of 
management. Any information system, or any . 

significant revision of an information system which 
is in cost or importance less than Class II is a 
Class III system. 

d) For the purpose of estimating acquisition costs the 
value of one person-year of professional effort will 
be $100,000 regardless of the sources. 

Milestone Decisions 

Three milestone decisions are defined for acquisition of 

Major Information Systems. 

o Milestone 0 Decision — Approval of Mission Need 
Statement approval of the budget and schedule, 
and authorization to proceed to the next program 
phase. The Mission Need Statement shall define 
the need for the system, and shall be 
accompanied by Preliminary System Requirements, 
acquisition strategy, schedule goals, and the 
total and annual investment of resources 
estimated. The next program phase for a simple 
package (no program development investment, 
e.g., a computer with standard support software) 
is the actual procurement, or for a complex 
system development. The next phase is the 
Concept Development Phase. 


Milestone 1 Decision — Approval of the System - 
Design Concept, System Requirements, and Program 
Development Plan; and authorization to proceed 
with the next program phase. For large complex 
systems, alternate concepts are to be explored 
and evaluated before settling on a cnosen 
concept, the reasons for a particular selection 
are to be presented. Documentation at this 
stage shall include baseline System 
Requirements, System Design Concept, and a 
Program Development Plan. System requirements 
will be accredited by the IHSA. Cost and 
schedule goals are reassessed. Equipment plans 
are presented for approval, and acquisition of 
fully designed, commercial hardware . wi 11 
normally be executed pursuant to this approval 


Approved For Release 200 


R00040003001 0-2 


. Approved For Release 


890R000400030010-2 


or direction. Approved programs then proceed to 
the Preliminary Design Phase. 

o Milestone 2 Decision — Approval of the 
Preliminary Design and Revised Program 
Development. All acquisition programs, however 
phased, will have a single Preliminary Design 
Review (PDR) covering the entire program. This 
review is coordinated with the program's 
internal PDR so that issues arising as a result 
of the PDR process can be evaluated. At this 
milestone review the program cost, 
functionality, and schedule objectives, 
primarily as defined and determined at the PDR, 
are reassessed. Approved programs then proceed 
to full-scale development. 

At each decision milestone, guidance and direction to 
the program are documented. 

At any point at which a program deviation in cost or 
schedule goals of more than 15 percent is estimated, 
the IHSA will be notified. He may, at his discretion 
convene an ad hoc r eview of the project status. 

Procedures 

At least six months prior to Milestone 1 or 2 review of 
Class I and II systems the program sponsor will notify 
the IHSA. For Class I systems, the IHSA will coordinate 
and schedule an EXCOM review. 

The IHSA will appoint a member of his staff to 
coordinate with the program office concerning 
preparation for the Milestone review. The program ' 

office will brief the IHSA office with respect to the 
program status for Class I and II systems. ' Questions 
which the office of the IHSA has with the project will 
be addressed to the project management. The intent is 
to resolve all the questions that pertain to such 
matters as the project formulation, completeness of 
planning and design, interoperability, conformity with 
standards, and supportability prior to the Milestone 
review. 

Shortly prior to the review, the IHSA will prepare brief 
point papers covering any points of concern or 
disagreement relative to the information system's 
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development. Approximately one week prior to the EXCOM 
Milestone review of Class I systems, the IHSA will 
prebrief the EXCOM concerning unresolved issues and 
concerns. The project management will then brief the 
EXCOM on the system at the Milestone review. The IHSA 
will then prepare a decision coordinating paper 
documenting the EXCOM guidance and direction to the 
project. 

For Class II systems, if the IHSA feels that there are 
significant architectural concerns, he may join the 
Milestone review. If those concerns still remain 
following the review, the IHSA may schedule an EXCOM 
review. 


IHSA Responsibilities 

the Information System review process is the management 
compliment to the budgeting process. Information System 
decisions must fit into the affordability framework of 
the budget, and further, must fit into the Agency 
architecture and planning framework for Information 
Systems. In that context specific IHSA responsibilities 
include: 

a) Formulating overall architecture tenets for 
Information Systems 

b) Conducting formal reviews of proposed 
Information Systems to: 

o Accredit requirements 

o Determine compliance with architecture 

tenets \ 

\ 

o Validate Functional Requirements 

v 

o Validate System Concept \ 

o Ensure that relevant interfaces are 
considered 

o Validate information security of proposed 
design 

c) Advising on relative priorities of Information 


-A5- 


Approved For ReleareCO 




00890R00040003001 0-2 


Approved For Release 2003/06/20 : CIA-RDP84B00890R000400030010-2 

CONFIDENTIAL' 


Systems 

d) Focusing the issues for EXCOM reviews 

e) Making an annual report to the EXCOM on the 
status of IHSs in the Agency and advising EXCOM 
on Information Systems decisions 

f) Designated individual for the Agency assuring 
compliance with government— wide standards and 
procedures. Included is assuring Agency 
compliance with Federal Information Processing 
Standards, or granting waivers these to in 
accordance with delegated authorities and 
specified procedures. 


ILLEGIB 
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